Orchestration vs Choreography 差異

首先介紹這兩個名詞，在中文常都被翻譯成「編排」，但實際內涵不同：

• Orchestration（編排）: 由中心流程引擎協調各服務，單一流程擁有者，適合長流程、需要補償與強稽核。
• Choreography（編舞）: 透過事件彼此互動，去中心化，適合簡單鬆耦合與廣播通知。
• 混合模式：真實系統中常見混合做法，一部分使用事件廣播（EDA），但核心交易仍依靠中心編排（Workflow Engine)。

當談到 Workflow Orchestration 通常也是指由 Workflow Engine 來進行編排，下列流程引擎所需能力。

流程引擎能力總覽

• 特性: 集多種特性於一身，集中化流程定義、狀態管理、內建重試/補償、事件驅動、可視化工作流程、長時間執行支援
• 使用情境: 長時間運行的業務流程、跨服務交易處理、需要補償機制的複雜流程、互動式人機協作流程、需要可靠執行的關鍵業務邏輯
• 誤用: 用於簡單獨立工作、當作訊息或事件匯流排使用、過度集中化所有業務邏輯、沒有狀態需求的簡單流程
• 陷阱: 過度使用導致架構僵化、非確定性工作流導致回放問題、忽略版本管理和兼容性問題、未考慮效能開銷
• 導入複雜度: 初始的學習曲線高，需要理解工作流概念和平台特性
• 維護複雜度: 長期維護成本趨於穩定，心智負擔後期不會隨系統複雜度飆升
• 可觀測性: 完整的歷史記錄與當前狀態檢視，支援跨服務追蹤，提供執行時間與資源使用統計
• 流程可見性: 內建監控與追蹤，視覺化工作流程圖表，完整審計日誌，支援執行回放和模擬測試

為了避免誤用踩到陷阱，以下列出與排程及事件驅動的適用情境做為比較。

應用情境比較

📊 流程引擎 vs 排程 — 適用 & 誤用情境

📊 流程引擎 vs 事件驅動 (EDA) — 適用 & 誤用情境

目前適用於編排的流程引擎介紹

• Camunda: BPM 陣營自 2000 年前後開始發展，歷史悠久、成熟度極高，但長期以來常被認為只是企業簽核專用。然而簽核流程其實同樣牽涉系統、人員與狀態的協調，本質上所面對的挑戰與分散式架構相同。(Camunda 8 改為事件流架構，支援水平擴展，和 Camunda 7 傳統單體不同。)
• Conductor: 是由 Netflix 打造的流程引擎，最初在 2015 年用於內部的微服務協調，2016 年正式開源。它以 JSON 格式來描述與定義流程，適合管理跨服務的任務依賴與長流程編排；許多大型企業也在使用。現由 Orkes 維護並提供商業化版本。
• Temporal: 前面介紹的都是用圖形化介面來做流程編排，本系列文章的主角有些特別，它提供多種程式語言的 SDK，讓開發者可以用自己的程式語言直接編寫流程，而不是透過 BPMN、YAML 或 JSON DSL。
• 雲端平台: 三大雲商各有流程引擎（AWS Step Functions、Azure Durable Functions、Google Cloud Workflows），與自家服務整合度高，但通用性較弱。

其他相關工具

• Spring Web Flow: Web 應用導向流程。
• Airflow: 主要用於 Data pipeline/ETL 導向的引擎。
• n8n: 內建各類服務的連接器，視覺化上手快；但狀態/長流程/錯誤處理較弱。適合中小企業快速自動化，但 不適合需要 SLA、補償、狀態的關鍵業務流程。

結語

2015–2017 算是新一代引擎的起點，顯示這個需求在微服務與雲原生架構普及後被真正放大。

• Conductor：2015 Netflix 內部使用，2016 開源。
• Cadence：2015–2016 Uber 內部開發，2017 開源。
• Zeebe：2015 開始開發，2018 open beta，2021 整合到 Camunda 8。
• Step Functions：2016 AWS re:Invent 推出。

其實更早在 2000 年前後，BPM 陣營（jBPM、Activiti）就已經處理流程建模與系統/人員協調的問題，但主要針對企業簽核、系統整合，尚未可以處理 massive scale 的分散式挑戰。新一代引擎則是把事件驅動、雲原生架構 引入，引擎角色從「企業簽核工具」擴展為「分散式協調核心」。

因此，只要能正確識別需求，就能理解流程引擎雖不是萬靈丹，但在諸多場景（長流程、補償交易、狀態保存、跨服務協調）中是非常關鍵的解決方案。

下一篇將進一步介紹本系列主角 Temporal 的基礎架構。